Most computing devices, applications and complex tools rely upon a graphical user interface to interact with, receive input from and provide information to users. There are many types of user interfaces which can be implemented and they can include graphical user interfaces (GUI), character user interfaces (CUI) and web-based user interfaces. The development of such software containing user interfaces, more specifically GUIs, involves the testing and verification of the performance and proper functionality of the GUI being tested. GUI testing can be performed via manual interaction sufficient to ensure that all crucial aspects of the GUI are properly covered. Depending on the complexity of the GUI, the number of manual operations required to test the GUI can easily be of a large magnitude. As an alternative to manual checking, a GUI automation program can be used to automatically simulate these otherwise manual operations. Since a GUI automation program is software in itself, it also requires testing to ensure proper functionality.
Automated GUI testing can include performing a predefined set of GUI automation program functions on the GUI of a computer program under test (CPUT) while a debugger program works to ensure the GUI automation program is functioning properly. During this process, the CPUT's GUI normally has the focus of the display. The GUI automation program and the debugger program typically operate in an integrated development environment (IDE) GUI displayed behind or alongside the CPUT's GUI. During the process of debugging an application, the debugger program's GUI assumes the focus and is displayed in front of the CPUT's GUI in order to provide information, such as a stack trace, variable values, and current lines of code, to the user. This assumption of focus by the debugger program's GUI occurs when the debugger detects a break in the execution of the GUI automation program, e.g. when a breakpoint is “hit”. Once the debugger program has the focus, focus may not return to the CPUT's GUI without user input. When focus has been restored to the CPUT's GUI, certain attributes of that GUI, such as any context menu displayed at the time the breakpoint was hit, may no longer appear. In that case, the GUI automation testing may not be able to properly continue its predefined set of GUI automation program functions, because the CPUT's GUI is no longer in the anticipated state after the breakpoint has been hit.
A similar problem can occur during debugging of a CPUT without GUI automation. If a breakpoint is hit while a context menu with programmatically-determined content is displayed, and if further debugging toward a desired program state relies on the display of that original context menu content, then further useful debugging may not be possible after the breakpoint has been hit, unless the CPUT is restarted and debugged again from the beginning.